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1.  Introduction 


The  lethality/vulnerability  server  (the  lethality  server)  is  a  tool  allowing  diverse  applications  to 
draw  from  the  same  vulnerability  description  data  set  during  a  simulation  run.  Configuration  of 
the  vulnerability  damage  is  done  once  and  for  all  serviced  applications.  The  lethality  server 
currently  delivers  data  descriptions  in  terms  of  standard  fully  damaged  “mobility,”  “firepower,” 
and  “catastrophic”  states.  With  relatively  minor  modifications,  the  server  can  be  expanded  to 
deliver  partial  (or  degraded)  damage  and  other  types  of  data. 

This  document  is  a  functional  description  of  the  server  with  an  emphasis  on  its  high  level 
architecture  (HLA)  interface  for  the  Modeling  Architecture  for  Technology  and  Research 
Experimentation  (MATREX)  VO. 5  release  (1,2,3). 


2.  MATREX  Architecture 


A  short  introduction  to  the  MATREX  architecture  will  help  provide  a  better  context  for  the 
lethality  server.  Distributed  simulations  have  had  great  success  within  the  Department  of 
Defense  (DoD)  community,  particularly  in  the  area  of  training  (for  example,  joining  together 
flight  simulators  or  annored  vehicle  simulators  augmented  by  semi-automated  simulated 
opposition  forces).  Among  the  many  success  stories  are  SIMNET  (simulation  network) 
developed  in  the  early  1980’s  and  the  ensuing  Close  Combat  Tactical  Trainer  (CCTT)  delivered 
in  the  1990’s  (4,5).  Traditionally,  these  distributed  simulation  environments  have  been  defined 
by  joining  simulators  (or  models)  that  are  stand-alone  applications  in  their  own  right.  These 
simulations  provide  state  revisions  for  the  benefit  of  remote  applications.  MATREX  builds  upon 
object-oriented  techniques  and  the  foundation  provided  by  the  Joint  Virtual  Battlespace  (JVB) 
(6).  In  such  approaches,  the  synthetic  environment  segments  the  simulation  space  into  a  set  of 
composible  services  that  may  be  called  upon  when  necessary  (as  portrayed  in  figure  1 ;  figure  2 
displays  an  overall  logical  architecture  of  the  MATREX  concept).  Some  advantages  to  the 
component  approach  shown  in  figure  1  have  already  been  mentioned  with  regard  to  the  lethality 
server,  namely,  streamlining  data  configuration  and  ensuring  that  all  simulations  are  accessing 
the  same  validated  source  data,  algorithms,  or  component. 
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Classic 


MATREX 


Figure  1.  MATREX  component  architecture  approach  (1,  p  30). 


MATREX  VO. 5  was  developed  and  delivered  to  the  Future  Combat  System  of  Systems  (FCS) 
lead  systems  integrator  in  December  2003.  It  incorporated  a  number  of  simulation  services,  data 
servers,  and  simulation  components  to  include  the  lethality  server.  Some  of  these  are  shown  in 
their  logical  organization  within  figure  2.  This  figure  represents  conceptual  components  and 
some  potential  interfaces  (such  as  test  and  training  enabling  architecture  (7),  shared  memory, 
etc.)  that  do  not  portray  the  actual  set  of  delivered  articles.  This  figure  is  shown  merely  to 
provide  a  better  understanding  of  the  MATREX  approach;  other  sources  can  provide  a  deeper 
understanding  (7).  The  delivered  MATREX  VO. 5  run  time  components  were  orchestrated  into 
an  HLA  federation  object  model  and  heavily  tested.  The  lethality  server’s  HLA  object  model 
interface  to  the  MATREX  environment  is  this  report’s  main  topic  and  is  addressed  now. 
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Figure  2.  MATREX  logical  architecture  (7,  p  36). 


3.  HLA  Interface 


This  section  describes  the  HLA  interface  of  the  U.S.  Army  Research  Laboratory’s  (ARL)  table 
lookup  lethality  server  integrated  into  the  MATREX  science  and  technology  objective  (STO). 
Descriptions  of  the  lethality  server’s  object  model  components  are  given.  Additional  MATREX 
HLA  objects  are  referenced  but  are  not  explained  in  detail. 

The  simulation  interactions  in  the  MATREX  federation  object  model  (FOM)  are  grouped  into  a 
class  structure.  There  is  a  “root  service”,  SimulationService,  from  which  lethality  services  and 
other  service-related  interactions  can  be  derived.  The  lethality  server’s  interaction  class  structure 
is  shown  in  table  1 . 


Table  1 .  Lethality  server  interaction  class  structure. 


Interactioni 

Interaction 

Interactions 

SimulationService  (IR) 

Lethality  (IR) _ 

Lethality  Query  (IR) _ 

Lethality  Respome  (IR) 

This  lethality  class  structure  corresponds  to  a  query-response  mechanism  which  is  depicted  in 
figure  3. 


Any  Federate  Lethality  Server 

SimulationService. Lethality. LethalityQuery 
(queries  the  server  for  data  -  unimplemented) 

SimulationService. Lethality.LethalityResponse 
(server  responds  -  unimplemented) 

Figure  3.  Query  and  response  interaction. 

A  federate  can  query  the  lethality  server  for  damage  data.  The  query  is  made  when  a  federate 
issues  a  SimulationService.Lethality.LethalityQuery  interaction.  The  lethality  server  responds  to 
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the  query  by  finding  the  results  based  on  the  passed  parameters  and  issues  a  SimulationService 
Lethality. LethalityResponse  interaction.  Tables  2  and  3  list  and  explain  the  parameters  of  the 
LethalityQuery  and  LethalityResponse  interactions.  This  query-response  designed  feature  is 
currently  not  implemented  in  the  delivered  MATREX  VO.  5  version  of  the  server. 


Table  2.  SimulationService. Lethality. LethalityQuery  interaction. 


Interaction 

Object 

Parameter 

Data  Type 

Parameter  Description 

Lethality 

Query 

EntitylD 

String 

The  identifier  of  the  entity  whose  damage  status  is  being 
queried. 

Querying 

Initial 

Conditions 

Boolean 

If  TRUE,  the  lethality  server  is  to  return  initial  conditions 
data  used  for  damage  calculations  on  the  queried  entity. 

Querying 

Probability 

Distribution 

Boolean 

The  Boolean  to  indicate  that  the  lethality  server  is  to 
return  the  probability  distribution  used  in  the  damage 
calculation. 

Table  3.  SimulationService. Lethality. LethalityResponse  interaction. 


Inter¬ 

action 

Object 

Parameter 

Data  Type 

Parameter  Description 

Lethality 

Response 

Probability 

Distribution 

MFK 

Double  *  5 

Five  doubles  that  comprise  the  probability  distribution  used  to 
compute  damage. 

(This  is  in  “thermometer”  distribution  (5)  format.) 

The  server  does  not  fill  this  field  in  the  MATREX  VO.  5  delivery; 
however,  for  V&  V purposes,  these  data  are  printed  on  the 
server’s  console  (standard  output)  along  with  the  file  name  of 
the  vulnerability  data  table. 

Initial 

Conditions 

String 

The  initial  conditions  used  to  compute  damage 
(a  human-readable  list  of  parameters  and  values). 

Query  ID 

Federate 

IDCDT 

Normally,  this  would  be  the  ServicelD  of  the  LethalityQuery 
interaction  associated  with  this  response. 

However:  For  MATREX  VO. 5  since  queries  are  not 
implemented,  this  parameter  references  the 
MunitionDetonationServicelD  of  a  single  detonation  event. 

The  rest  of  the  parameters  all  are  in  the  context  of  this 
detonation  event. 

Instantaneous 

Damage 

Damage 

StatusEDT 

The  damage  state  of  the  entity  being  queried. 

ErrorFlag 

Boolean 

The  flag  indicating  whether  the  lethality  calculation  was 
successful.  If  TRUE,  then  some  error  occurred  and  the  damage 
calculation  was  not  successful.  This  will  indicate  that  the  value 
of  the  InstantaneousDamage  parameter  is  not  valid. 

ErrorMessage 

String 

If  an  error  occurred  (“ErrorFlag”  ==  TRUE),  this  field  may 
contain  an  error  message. 

ResultsFlag 

Lethality 

ErrorEDT 

The  enumerated  value  indicating  the  results  of  the  damage 
calculation.  This  field  will  indicate  either  success  or  the  reason 
for  failure  (see  table  5). 

ResultsFlag 

Text 

String 

A  short  text  explanation  of  the  ResultsFlag  parameter. 
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What  does  the  server  implement?  In  general,  the  lethality  server  broadcasts  damage  resulting 
from  some  event.  In  the  current  version  of  the  lethality  server,  when  a  MunitionDetonation 
interaction  occurs,  the  server  broadcasts  the  result  damage  to  the  target  by  means  of  a 
DamageReport.  This  is  depicted  in  figure  4.  The  DamageReport  interaction  contains  the 
damage  information  of  the  targeted  entity.  Table  4  lists  and  explains  the  parameters  within  the 
DamageReport  interaction  objects. 


Figure  4.  DamageReport  interaction. 


The  server  provides  additional  details  for  each  DamageReport  via  the  SimulationService. 
Lethality. LethalityResponse  interaction  class.  This  interaction  is  implemented  and  issued  for 
every  detonation  event.  The  parameters  returned  by  this  interaction  can  be  useful  for  validating 
the  vulnerability  process  because  they  expose  initial  conditions  and  other  items  required  to 
ensure  that  the  server  is  functioning  properly.  You  can  turn  this  feature  off  by  starting  the  server 
with  the  “-0  AllwaysSendQueryResponseOFF”  option. 

The  lethality  server  uses  munition-target  interaction  tables  to  calculate  damage.  The  data  in 
these  tables  are  based  on  pristine  targets  (no  previous  damage).  As  a  result,  the  damage  data  that 
are  returned  from  the  server  are  not  cumulative  and  do  not  take  into  account  the  affected  entity’s 
current  damage  state.  For  instance,  if  as  a  result  of  a  hit,  a  target  suffered  a  mobility  kill  (M-Kill) 
and  after  a  second  hit,  experienced  a  firepower  kill  (F-Kill),  the  final  damage  state  would  be  an 
F-Kill.  It  is  the  responsibility  of  the  entity  to  combine  any  new  damage  with  its  current  damage 
state. 
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Table  4.  SimulationService. fireengagement.damagereport  interaction.  (Datatypes  are  defined  in  the  MATREX  VO. 5 
FOM.) 


Interaction 

Object 

Parameter 

Data  Type 

Parameter  Description 

Damage 

Report 

DamageState 

Damage  StatusEDT 

The  assessed  damage  state. 

Damage 

Location 

LatLongAlt 

PositionCDT 

The  location  at  which  the  damage  is  assessed. 

FireDirective 

ServicelD 

Federate 

IDCDT 

The  ServicelD  of  the  FireDirective  interaction  that  caused 
this  DamageReport  to  occur.  This  is  set  to  null  if  there  was 
no  preceding  FireDirective  interaction. 

TriggerPull 

ServicelD 

Federate 

IDCDT 

The  ServicelD  of  the  TriggerPull  interaction  that  caused 
this  DamageReport  to  occur.  This  is  set  to  null  if  there  was 
no  preceding  TriggerPull  interaction. 

WeaponFire 

ServicelD 

Federate 

IDCDT 

The  ServicelD  of  the  WeaponFire  interaction  that  caused 
this  DamageReport  to  occur.  This  is  set  to  null  if  there  was 
no  preceding  WeaponFire  interaction. 

Munition 

Detonation 

ServicelD 

Federate 

IDCDT 

The  ServicelD  of  the  MunitionDetonation  interaction  that 
caused  this  DamageReport  to  occur.  This  is  set  to  null  if 
there  was  no  preceding  MunitionDetonation  interaction. 

ServicelD 

F  ederate 

IDCDT 

The  unique  identifier  that  tracks  a  simulation  request, 
response,  and  event  chain.  This  is  inherited  from  the 
SimulationService  class. 

Timestamp 

Unsigned  long  long 

The  simulation  time,  in  seconds  and  fractions  of  a  second 
from  midnight,  1  January  1900,  at  which  the  parameter 
values  in  this  interaction  are  valid.  This  is  inherited  from 
the  SimulationService  class. 

FiringID 

String 

The  EntitylD  of  the  object  firing  the  munition.  This  is 
inherited  from  the  FireEngagement  class. 

TargetID 

String 

The  EntitylD  of  the  object  being  fired  at  (if  any).  This  is 
inherited  from  the  FireEngagement  class. 

MunitionID 

String 

The  EntitylD  of  the  associated  munition  object  (if  any). 

This  is  inherited  from  the  FireEngagement  class. 

MunitionType 

MunitionTypeEDT 

The  type  of  munition  that  is  detonating.  This  is  inherited 
from  the  FireEngagement  class. 

WarheadType 

WarheadTypeEDT 

The  type  of  warhead  on  the  munition.  This  is  inherited 
from  the  FireEngagement  class. 

The  enumerated  data  type  developed  for  the  lethality  server,  LethalityErrorEDT  is  defined  in 
table  5.  LethalityErrorEDT  is  only  used  in  the  “ResultsFlag”  parameter  from  the 
“Lethality Response”  interaction  shown  in  table  3.  The  other  enumerated  data  types  listed  in  this 
document  are  defined  in  the  MATREX  VO. 5  FOM:  DamageStatusEDT,  MunitionTypeEDT,  and 
WarheadTypeEDT. 


Table  5.  Enumerations. 


Identifier 

Enumerator 

Representation 

LethalityErrorEDT 

Success_No  Error 

0 

ErrorJJnknown 

1 

ErrorJMo  LookupTable  Found 

2 

Error_CorruptTable 

3 

Error_MissingEnvironmentData 

4 
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Table  6.  Interactions  (server  subscribed). 


Object 

Usage 

MunitionDetonation  interaction 

Triggers  the  server  to  broadcast  the  resulting  damage 

WeaponFire  interaction 

Some  of  this  information  may  be  used  to  calculate 
MunitionDetonation  damage 

4.  Data  Configuration 


The  server  only  issues  DamageReport  interactions  for  munition-target  pairings  that  are 
specifically  listed  in  its  database.1  This  database  is  a  flat  file  rneta  record  currently  situated  in 
“$VLS_HOME/Data/hut/Matrex_V05_Meta.dat”.  However,  this  particular  file  name  is 
configurable  and  defined  in  “$VLS_HOME/Data/Init/vls_db_init.ini”  as  described  in  section  5. 

4.1  Configured  Vehicles/Threats 

The  list  of  MATREX  VO. 5  targets  and  threats  configured  in  the  server  is  displayed  in  tables  7 
and  8. 


Table  7.  List  of  vehicle  types  arbitrated  by  the  lethality  server  (MATREX  VO. 5). 


FOM  Vehicle  Type 


Platform  FOM 
Enumeration 

OTB  Platform  Name 

Platform  Description 

RAH66 

vehicle_US_RAH66_AVCATT 

RAFI-66  Comanche 

Shadow200 

vehicle_US_SHADO  W200  FD 1 

Unmanned  Aerial  Vehicle  -  Class  IVa  (UAV  (CL 
IVa)) 

SoldierUGV 

vehicleU  SLST1MULE 

Multi-Function  Utility/Logistics  and  Equipment 
(MULE)  Vehicle 

LSTIHMMWV 

vehicle  US  LSTI  HMMWV 

HMMWV 

LSTISUAV 

vehicleUSLSTISUAV 

Unmanned  Aerial  Vehicle  -  Class  III  (UAV  (CL 

HI)) 

L  S  T1_0  A  V_LT 

vehicleU  SLST IOAVLT 

Unmanned  Aerial  Vehicle  -  Class  I  (UAV  (CL  I)) 

LST1ARVC1 

vehicleUSLSTIARVCl 

Armed  Robotic  Vehicle  -  Assault  Variant,  Light 
(ARV-A  (L)) 

LST1BLOS 

vehicleUSLSTIBLOS 

Mounted  Combat  Systems  (MCS) 

LSTIIC 

vehicleU  SLSTIIC 

Infantry  Carrier  Vehicle  (ICV) 

LSTIRSTA6 

vehicleU  SLSTIRST  A6 

Reconnaissance  and  Surveillance  Vehicle  (R&SV) 

LSTIC2 

vehicle_US_LSTI_C2 

Command  and  Control  Vehicle  (C2V) 

M1079 

vehicle_US_LSTI_M1079 

LMTV  -  Van 

FCS  BOX  NETFIRE 
FD1 

vehicle  US  FCS  BOX  NETFIRES 
FD1 

Non-Line-of-Sight  Launch  System  (NLOS  LS) 

During  certain  circumstances,  users  may  want  the  server  to  produce  invalid  damage  assessments  even  if  there  are  no 
vulnerability  data  for  some  munition  and  targets.  To  have  the  server  issue  a  "DamageReport”  even  when  lacking  vulnerability 
data  (i.e.,  produce  fantastical  DamageReports),  start  the  server  with  the  command  line  option:  -O  AllwaysSendDamage  ON  If 
this  option  is  turned  on  and  there  are  no  vulnerability  data  to  describe  an  event,  then  the  damage  states  issued  are  undefined. 
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LST1  NLOS  CANNO 
N 

vehicle  US  LSTI  NLOS  CANNO 

N 

Non-Line-of-Sight  Cannon  (NLOS  Cannon) 

LSTI  NLOS  MORTA 
R 

vehicle  US  LSTI  NLOS  MORTA 
R 

Non-Line-of-Sight  Mortar  (NLOS  Mortar) 

BMP2 

vehicleU  S  SRBMP2 

BMP-2  Armored  Fighting  Vehicle 

BRDM2 

vehicle_USSR_BRDM2 

BRDM-2  Armored  Reconnaissance  Vehicle 

BTR80 

vehicle_USSR_BTR80 

BTR-80  APC 

GAZ66 

vehicle_USSR_GAZ66 

GAZ-66  Truck 

MTLBU 

vehicleUSSRMTLBVAVCATT 

MT-Lbu  (1V12)  Artillery  Command  &  Recon 
Vehicle 

BMP1 

vehicleU  S  SRBMP 1 

BMP-1  AFV  surrogate  for  PT-  76 

ZSU23_4 

vehicle_USSR_ZSU23_4 

Quad  23  mm  AAA  Gun  System 

ZIL131 

vehicleU  S  SRZIL 1 3 1FDC 

6x6  Truck 

HOW2S12 

vehicle_USSR_2S19 

152mm  SP  Flowitzer 

T_72M 

Vehicle_USSR_T72M 

T-72  Tank 

BM21 

V  ehicleU  S  SRBM2 1 

Multiple  Rocket  Launcher 

Table  8.  List  of  munition  types  arbitrated  by  the  lethality  server  (MATREX  VO. 5). 


FOM  MunitionType 

Munition  FOM  Enumeration 

Munition  Description 

munition  US  M829A2 

KE  M829E3  (72)  Tank  Main  Gun 

munition  US  M830A1 

KE  M830A1  (73)  HEAT  Tank  Main  Gun 

munition_USSR_  1 25F1EAT 

Tank  Main  Gun  Round  HEAT 

munition_USSR_125SABOT 

Tank  Main  Gun  Round  KE 

munition_USSR_Sagger 

AT  Missile  AT-3  ATGM 

munitionUS  SRSongster 

AT  Missile  AT-8  ATGM 

munition_USSR_Spandrel 

Spandrel  AT-5  ATGM 

munition  US  Flellfire 

Comanche  AGM-1 14  Hellfire  ATGM  SAL 

munition_US_Flydra70_M15 1 

2. 75 in  Rocket  HE 

munition  US  Flydra70  M261 

2.75in  Rocket  HE  Submunition 

munition  US  Javelin 

Javelin  ATGM 

munition  US  Stinger 

FIM-92A  Stinger  AA  Missile 

munition  US  TOW 

TOW  Missile  BGM-7  ID 

munition  US  TOW2B 

TOW  Missile  BGM-7  IF 

4.2  Known  Missing  Data 

All  possible  munition-vehicle  permutations  (from  tables  7  and  8)  are  configured  in  the  server’s 
rneta  data  record  (“$VLS_HOME/Data/Init/Matrex_V05_Meta.dat”)  with  the  exception  of  the 
following  munition-vehicle  pairings  shown  in  table  9.  Most  of  these  are  “friendly”  munitions 
attacking  “friendly”  targets  or  otherwise  have  a  low  likelihood  of  occurring  in  a  normal 
battlefield  scenario. 
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Table  9.  Missing  vulnerability  data  in  the  server’s  MATREX  VO. 5  delivery  configuration. 
(Missing  pairing  marked  by  ‘o’.) 


Munition  | 
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vehicle_ 

US  LSTI  NLOS  CANNON 

0 

0 

vehicle_ 

US  LSTI  NLOS  MORTAR 

0 

0 

vehicle_ 

US  LSTI  OAV  LT 

0 

0 

0 

0 

vehicle_ 

US_LSTI_OAV_MED 

0 

0 

0 

0 

vehicle 

US  LSTI  RSTA6 

0 

0 

vehicle_ 

US  LSTI  SUAV 

0 

0 

D 

D 

0 

0 

vehicle_ 

U  S_RAH  66AVCATT 

0 

0 

0 

0 

vehicle 

US  SHADOW200  FD1 

0 

0 

D 

D 

0 

0 

vehicle_ 

USSR  2S1 9 

0 

vehicle 

USSR  BMP1 

0 

vehicle 

USSRBMP2 

0 

< 

CD 

=7 

o' 

CD 

USSR  BRDM2 

0 

< 

CD 

=7 

o' 

CD 

USSR  BTR80 

0 

vehicle_ 

USSR  MTLBV  A VC ATT 

0 

vehicle 

USSR  T72M 

0 

vehicle_ 

USSR  ZIL131  FDC 

0 

vehicle_ 

USSR  ZSU23  4 

0 

5.  Initializing  the  Server 


This  section  explicitly  notes  server-starting  options  and  references  the  fonnats  and  locations  of 
initialization  files  and  other  preparatory  infonnation  required  to  start  the  server. 

5.1  Server  Initialization  Files 

The  environmental  variable  VLS  HOME  must  be  set  to  point  to  the  directory  where  the  lethality 
server  was  installed.  Primarily,  this  lets  the  server  find  its  set  of  initialization  and  vulnerability 
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data  files.  Initialization  files  are  situated  in  the  Data/Init  subdirectory  relative  to  VLSHOME. 
That  is,  initialization  data  files  are  in  the  directory 

$ {VLS_HOME} /Data/Init/ 

The  main  initialization  file  in  this  directory  is  vls_db_init.ini.  This  file  tells  the  server  where  to 
find  all  the  other  initialization  files.  Only  three  initialization  files  are  identified  by 

vls_db_init.ini: 

1 .  A  Distributed  Interactive  Simulation  (DIS)  (9)  enumeration  file;  these  are  the  names  and 
equivalent  DIS  numerical  representation  for  entities,  munitions,  etc.  More  than  6,000 
Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  standard  enumerations  are 
provided. 

While  the  server  is  completely  an  HLA  application,  internally  it  retains  DIS  enumerations  to 
identify  vehicles  and  munitions.  These  DIS  enumerations  are  mapped  to  the  HLA  federation’s 
enumerations  via  two  source  code  header  files  called  “vehicles.h”  and  “munitions. h.”  (These  are 
situated  with  the  source  code  in  $VLS_HOME/src/HLAMon.MATREX/  and  include  all  vehicle 
and  munition  types  from  the  MATREX  VO. 5  scenario.  The  vehicles  and  munitions  shown  in 
tables  7  and  8  are  a  subset  of  the  MATREX  VO. 5  scenario  entities.)  Adding  new  munitions  and 
vehicles  (other  than  those  delivered  in  the  MATREX  VO.  5  scenario)  will  require  editing  of  these 
header  files  and  recompiling. 

2.  A  DIS  auxiliary  enumeration  file;  intended  for  “additional”  entities  added  for  a  particular 
exercise. 

3.  A  lethality  “ meta  data ”  file;  this  tells  the  server  all  it  needs  to  know  about  the  lethality  data 
to  be  delivered  upon  demand.  The  meta  data  file  contains  meta  data  records. 

A  lethality  meta  data  record  identifies  several  items  for  the  server.  First,  it  specifies  which  type 
of  V/L  analysis  method  is  used  when  a  particular  threat  attacks  a  certain  target.  Then  it  identifies 
where  the  data  are  that  describe  the  damage  state  outcomes  (with  respect  to  the  type  of  vulner¬ 
ability  analysis  method  in  question).  Finally,  the  meta  data  record  identifies  which  library 
functions  are  used  to  read  and  interpret  the  data  source.  (Identifying  a  library  function  allows 
flexibility  in  how  data  are  stored  and  retrieved.)  Vulnerability  data  need  not  be  just  static  “look¬ 
up”  tables. 

Further  details  about  vls_db_init.ini  and  the  meta  data  format  are  presented  in  the  document 
“VLS_DB_INIT(5),”  Revision  0.5,  March  1998  in  the  “$VLS_HOME/doc”  directory  or  in 
appendix  B  from  ARL  report  ARL-TR-1775  (5). 
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5.2  Server  Command  Line  Options 

The  executable  version  of  the  server  is  generally  in  the  directory: 

$ { VLS_HOME } /bin/vlserver . exe 
However,  for  MATREX  VO. 5,  the  execution  (and  main  source  code  files)  are  in 

$ { VLS_HOME } /src/HLAmon . MATREX/LethalityServer . exe 

After  setting  the  VLSHOME  environmental  variable  and  starting  the  MATREX  HLA  run  time 
infrastructure  (RTI)2,  the  server  may  be  started.  By  default,  the  server  will  find  the  RTI  and 
create  or  join  a  federation  named  “MATREXV0.5”.  The  federation  name  may  be  changed  in  the 
initialization  file  “LethalityServer.HLAfc”  situated  in  the  HLAmon.MATREX  starting  directory. 
Table  10  displays  other  options  that  are  selectable  on  the  command  line. 


Table  10.  Command  line  options. 


Command  Line  Option 

Result 

-V 

Verbose  mode. 

-L 

Log  FILA  traffic. 

Bytes  sent  to  and  received  by  the  FILA  RTI3  are  printed  in  a  log 

update  file  called  “ _ updateLog.log#someNumber#.” 

This  will  generate  a  large  human-readable  ASCII  text  file. 

-0  AllwaysSendDamage  ON 

AllwaysSendDamage  ON :  If  set,  the  server  will  issue  damage 
results,  even  if  it  has  no  data  for  the  munition  or  target  in 
question  (i.e.,  it  will  invent  a  damage  result  and  issue  that). 

By  default,  this  option  is  off. 

-0  AllwaysSendQueryResponseOFF 

AllwaysSendQueryResponse  OFF :  If  left  unset,  the  server 
will  issue  (usually  useful)  debugging  information  in  the 
“SimulationService. Lethality. LethalityResponse”  FOM 
interaction  class  for  all  MunitionDetonation  interactions 
(the  associated  MunitionDetonation. ServicelD  will  be 
referenced  in  the  LethalityResponse’s  “QuerylD”  field). 

5.3  Console  Commands 

As  delivered  in  MATREX  VO. 5,  the  server  does  accept  a  limited  number  of  commands  that  may 
be  typed  from  the  lethality  server  console  after  the  server  has  been  launched.  Table  1 1  explains 
these  commands  that  are  activated  when  the  indicated  key  is  typed  followed  by  the  return  (or 
enter)  key. 

The  VO. 5  executable  was  delivered  with  many  internal  “debug”  options  left  activated;  the  result 
is  an  almost  constant  stream  of  text  that  scrolls  across  the  console  window.  This  can  make  it 
difficult  to  distinguish  useful  command  results  from  the  constant  flow  of  debugging  output  and 
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“Instructions  about  starting  and  operating  the  RTI  are  not  covered  in  this  text.  The  HLA  RTI  used  for  MATREX  VO. 5  was 
RTI-NG  version  1.3NGjvbV3b.  You  may  obtain  this  RTI  and  its  operating  instructions  by  contacting  the  Joint  Precision  Strike 
Demonstration.  Project  Office,  Ft  Belvoir,  VA  or  Virtual  Technology  Corporation,  Alexandria,  VA  (http://www.virtc.com/). 

3This  RTI  is  the  last  version  of  the  Defense  Modeling  and  Simulation  Office  (DMSO)  distributed  HLA  RTI  (RTI-NG  1.3v6) 
with  additional  revisions  for  the  Joint  Virtual  Battlespace  and  MATREX  projects. 
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thus  limits  the  usefulness  of  console  commands  without  recompiling  a  new  executable  version  of 
the  server  with  less  text  flow. 

Table  11.  Console  commands. 


Key 

Command 

Description 

Q 

Quit 

Resign  from  the  federation  and  cease  execution. 

s 

Status 

Shows  the  “status”.  Status  in  this  case  is  simply  the  number  of  entities  being  monitored 
by  the  server.  Because  of  internal  accounting  mechanisms,  this  count  should  always  be 
two  greater  than  the  actual  global  entity  count. 

p 

Print 

Prints  all  data  known  about  every  entity  being  tracked  as  well  as  the  most  recently 
received  or  sent  interactions.  This  command  basically  is  a  data  “dump”  of  all  HLA  object 
model  classes  subscribed  to  and  published. 

6.  Summary 


The  ARL  table  look-up  server  has  undergone  numerous  changes  since  first  introduced. 
Originally,  it  was  a  DIS-only  application  using  transmission  control  protocol/intemet  protocol 
sockets  for  client  connectivity  (5).  Later  a  hybrid  HLA-DIS  interface  was  added  (10),  then  an  all 
HLA  interface  (11)  for  the  real-time  platform-level  reference  HLA  FOM  (RPR-FOM)  (12). 

Most  recently,  the  server  was  integrated  into  a  second  HLA  FOM  (MATREX)  requiring  internal 
and  external  changes.  This  report  described  the  server’s  MATREX  objects  and  parameters  that 
are  the  interface  to  the  server.  MATREX’s  composible  architecture  approach  was  also 
introduced. 

References  for  initializing,  starting,  and  executing  some  server  console  commands  were 
provided. 
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1  HQ  OPERATIONAL  TEST  CTR 

ATTN  CSTEOTCMAS  JHAMILL 
BLDG  91012 

FT  HOOD  TX  76544-5068 

1  SANDIA  NATIONAL  LABORATORIES 
ATTN:  M  J  McDONALD 
PO  BOX  5800  MS  1004 
ALBUQUERQUE  NM  87185-1004 

ABERDEEN  PROVING  GROUND 

1  DIRECTOR 

US  ARMY  RSCH  LABORATORY 
ATTN  AMSRD  ARL  Cl  OK  (TECH  LIB) 
BLDG  4600 

1  DIR  AMSAA 
ATTN  D JOHNSON 
BLDG  248 

2  DIR  AMSAA 

ATTN  B  BRADLEY  A  WONG 
BLDG  367 

3  DIR  AMSAA 

ATTN  D  HODGE  P  NORMAN 
K  STEINER 
BLDG  392 

5  US  ARMY  RESEARCH  LABORATORY 
ATTN  AMSRD  ARL  WM  BF 
S  WILKERSON 
G  SAUERBORN  (4) 

BLDG  390 


NO.  OF 

COPIES  ORGANIZATION 

6  US  ARMY  RESEARCH  LABORATORY 

ATTN  AMSRD  ARL  SL  BE  L  BUTLER 
R  BOWERS  C  KENNEDY 
J  ANDERSON  T  CHRISTY 
E  GREENWALD 
BLDG  238 

4  US  ARMY  RESEARCH  LABORATORY 

ATTN  AMSRD  ARL  SL  BB  R  SANDMEYER 
PTANENBAUM  B  WARD 
W  WINNER 
BLDG  328 

1  US  ARMY  RESEARCH  LABORATORY 

ATTN  AMSRD  ARL  SL  BE  L  ROACH 
BLDG  328 

3  US  ARMY  RESEARCH  LABORATORY 

ATTN  AMSRD  ARL  Cl  CT  G  MOSS 
M  THOMAS  P  JONES 

BLDG  321 

1  US  ARMY  RESEARCH  LABORATORY 

ATTN  AMSRD  ARL  Cl  CT  F  BRUNDICK 
BLDG  1116A 

1  DIR  USARL 

AMSRD  ARL  WM  W  J  SMITH 
BLDG  4600 

1  DIR  USARL 

AMSRD  ARL  WM  BA  D  LYON 
BLDG  4600 
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